home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Chip 1996 April
/
CHIP 1996 aprilis (CD06).zip
/
CHIP_CD06.ISO
/
hypertxt.arj
/
9504
/
TOMOR.CD
< prev
next >
Wrap
Text File
|
1996-03-08
|
28KB
|
516 lines
@Vùj tömörítôprogramok@N
@VBeindul a présgép@N
A 80-as évek végén, 90-es évek elején gyors és -- akkor
-- jónak számító tömörítô program gyakorlatilag csak egy
volt: a PkZip. Különösen az 1990-ben megjelent 1.10-es
verziója biztosította hosszú idôre a piaci egyeduralmát. Az
elkövetkezô években sorra jelentek meg a különbözô
konkurensek, de a PkZip állta a sarat.
Mindeközben megjelent az Info-Zip csapatnak a PkZippel
kompatibilis, de ZIP és UNZIP címen ingyenes programja.
Forráskódjukat is kiadták és ez magával hozta, hogy rengeteg
rendszerre átkerült a ZIP.
@VA jelen...@N
A 2-es sorozatnak '92-ben jelent meg az elsô
tesztverziója. Már ekkor nagy reklámkampány indult meg az új
verzió népszerûsítésére. '93-ban jelent meg a 2.04g -- eddig
utolsó -- PkZip verzió. (2.06-os verziója is létezik, de
csak az IBM belsô használatára.) E verziónak sok hiányossága
van, a legtöbb felhasználónak leginkább a rendesen megoldott
szeletelés hiányzik. Azonban tömörsége, gyorsasága, és a --
bár nem eredeti, de kompatibilis -- forráskód
hozzáférhetôsége mindennél elterjedtebbé tette. Rengeteg
kisebb-nagyobb segédprogram jelent meg hozzá, sok BBS és
Internet site kizárólag ZIP file-okat fogad el stb. Mindezek
ellenére nem lehetetlen a váltás -- a számítástechnika
mindig is a változások birodalma volt. Persze ennek
ellenkezôje is igaz: egyes bevált dolgokhoz hihetlen erôvel
tudnak ragaszkodni az emberek.
@V... és a jövô@N
Ez a helyzet alakult ki '94 végére. Decemberben -- talán
véletlenül -- egymás után jelent meg az AIN 2.2, a RAR 1.53
és az ARJ 2.42 (béta2). Elkezdôdött január elején az UC2 r3
bétatesztelése. Január végén megjelent a HA 0.99béta is.
Lássuk az újoncokat: vajon mennyiben jobbak elôdeiknél,
hogyan állják meg helyüket egymással -- és a jó öreg
PkZippel -- szemben?
@VAIN 2.2@N
Ez talán a legérdekesebb darab mind közül. A mellékelt
tesztbôl is látszik, hogy elsôsorban hihetetlen tempójával
hívja fel magára a figyelmet. Emellett még tömörsége
igen-igen jó, sôt ráadásként elég sok opciója is van. Persze
nincs annyi, mint az ARJ-nek: kevesebb mint 40 opciót ismer
annak a 150-nél is többjével szemben. Két fontos dolog
kimaradt: az idô alapján történô tömörítés és az archív
flagen alapuló backup. Azonban a szeletelést már-már
tökéletessé tették. Például újra tud szeletelni egy, már
tömörített archívumot, anélkül hogy újra tömörítené:
@KAIN Y /FA /OA:\ AKARMI@N
Ez a parancssor az archívumot másolja (copY) az A:\
könyvtárba (/O), úgy hogy azt teljesen megtöltse és szükség
szerint több lemezre kerülhessen (/FA). Sôt, akár az eredeti
archívum könyvtárában is képes ezt végrehajtani. Teljesen
egyedülálló módon képes a szeletelt archívum bármelyik
szeletébe belecsomagolni egy másik file-t. Mondjuk egy
BBS-azonosító file-t, mint a FILE_ID.DIZ.
A RAR egyáltalán nem enged szeletelt file-t módosítani,
az ARJ egy speciális kapcsolóval (/hu) engedi ezt -- de csak
az utolsó szeletre. Ezzel szemben az AIN tetszôleges
szeletbe enged beleírni, de ekkor nem veszi figyelembe a /f
kapcsolót, ha van. Azaz nem kezdi ezt a file-t is szeletelni
-- ami nem meglepô, hiszen ilyen igény rendkívül ritkán
léphet fel. Egészen pontosan: csak az utolsó szeletet engedi
tovább szeletelni. Mindezek után az .EXE file mérete: 36217
byte. Ezt a szintén mellékelt AINEXE.EXE tömörítô programmal
érték el. Mellékelnek még egy 22747 byte hosszú, csak
kicsimagolást végzô programot is.
Lássuk a hátrányait! Elôször is, mindig solid üzemmódban
dolgozik, kikapcsolhatatlanul. A /u kapcsolókkal bizonyos
mértékig szabályozhatjuk ezt: /u1 esetén egy file sérülése
szinte biztosan az összes többi utánajövôt is magával
rántja, míg /u3 esetén csak néhány file fog megsérülni.
Akadályozza a munkát a shareware emlékeztetô képernyô is.
Igaz, 20 dollár nem egetverô összeg, de sajnos kis hazánk
devizakörülményei nem tesznek lehetôvé olcsó és egyszerû
kijuttatást a legtöbb embernek. Hibának érzem, hogy az
egyszer szétszabdalt archívumot nem képes többé
""összeragasztani". Nagy bánatomra önkibontót sem tud
készíteni. Semmilyen forráskód nincs hozzá, így saját
programokban való használata korlátozott. Azonban az ARJ
nehezen áll meg vele szemben.
@VARJ 2.42 (béta 2)@N
Az ARJ már jól ismert, hiszen az elsô valódi
alternatívát ez a program nyújtotta a PkZippel szemben. Ez
az elsô, széles körben elterjedt tömörítô, ami jól tud
szeletelni. Annak, aki esetleg nem ismerné: a különbözô
szeletek neve azonos, de kiterjesztésük más. Az ARJ-nél az
egyes szeletek név-kiterjesztése alapbeállításban @KARJ, A01,
@KA02@N stb. îgy tárolható együtt az összes szelet mondjuk
winchesteren vagy szalagon. Szinte már riasztó az a
lehetôségáradat, amit a program kínál. Említsünk meg
néhányat: a legtöbb ARJ promptról kiadható DOS parancs,
kérés szerinti név-kiterjesztésû file-ok egy az egyben
tárolása (azaz nem veszteget idôt már tömörített file-okra),
idôpont szerinti különbözô csomagolások, egy menetben
tesztelés kérhetô stb. Az idô szerinti tömörítésnél
megadhatjuk, hogy egy adott idôpont elôtti, utáni, vagy két
idôpont közötti file-okat akarunk összeszedni. Ezt
összeillesztve azzal a képességgel, hogy még az archív
flaget is lekezeli, akkor egy backup programhoz jutottunk.
Szolgáltatásbôsége egyedülálló -- nincs olyan más tömörítô
program, ami ennyi opciót kínálna. Sôt, szinte semmilyen más
parancssoros DOS segédprogram nem kínál ekkora bôséget --
talán a PocketD kivételével. De a PocketD-nek -- és az
ARJ-nek is -- ez már hibája: egész egyszerûen képtelenség
150-200 opciót fejben tartani. Az ARJ /? parancsra megjelenô
helpje 15 Kbyte, két oszlopban szedve, ami kicsit nehezíti
az olvashatóságát. Mindezt a szolgáltatást egyetlen EXE file
nyújtja, mérete tömörítve körülbelül akkora, mint a (szintén
tömörített) RAR-é, 80 Kbyte. A 2.42-es verzió talán
legfontosabb újdonsága az önkibontó szeletelt archívum.
A program hátrányai között kell említeni viszonylagos
lassúságát. A mellékelt sebességtesztbôl kiderül, hogy a
kibontás sebessége mintegy a fele a ZIP-ének vagy az
AIN-ének. A tesztbôl nem látszik @Kegy@N file kibontásának a
sebessége. Ugyanis az ARJ mindig végigolvassa az archívumot,
és ebben teljesen egyedülálló. îgy persze nagyon lassú lesz,
különösen floppyra helyezett archívumoknál. Más tömörítôk
csak a solid üzemmódban pakolt archívumok bontásakor
darálják végig az archívumot. Felróhatjuk még a normális
forráskód teljes hiányát. Egy Unarj programnak ugyan
publikus a forrása, és ez néhány Unix rendszeren fut is, de
deklaráltan borzasztóan lassú. @K(Egyszerû puffereléssel
@Ktöbbszörösére gyorsítható az eredeti Unarj kód -- a szerk.)@N
@VHA .099béta@N
Ez a program minden lassúsági rekordot meg tud dönteni.
Meg lehet kérni arra, hogy az általa ismert mindkét
algoritmust próbálja meg, majd az adott esetben tömörebbnek
bizonyuló algoritmussal végezze el a tömörítést. A szokásos
bináris file-okon azonban a HA által ASC-nek nevezett
algoritmus nem igazán hatásos, a HSC pedig rettentô lassú
(ASCII file-okon sem sebességrekorder). Mindezek miatt elsô
tesztünkbôl -- a sok bináris file miatt -- ki is maradt a
HA, végeztünk egy második tesztet is több hasonló
szövegfile-lal. (A HA és a solid tömörítési algoritmus
jellemzésére ez utóbbi teszt a jó példa).
A HA-t olyankor érdemes használni, amikor az idô nem
számít, csak a tömörség a fontos mindenek felett.
Szolgáltatáskészlete az abszolút minimum közelében jár.
Ezzel szemben a program @Kteljes@N forráskódját kiadták. A
forráskód jól hordozható, mivel minden gépfüggô rutint külön
file-ba raktak. A program olyan algoritmusokat is használ,
amit eddig forráskódban még nem láthattunk, ezért sokan
olyan jelentôséget jósolnak neki, mint az AR002-nek. (Az
AR002-t azzal a céllal írták és adták ki, hogy mások
továbbfejlesszék. Ez meg is történt: a ZIP 2.x, az ARJ, az
UC2 mind erre a forrásra épít.) îgy elôfordulhat, hogy a HA
forrására építve új, különlegesen jól tömörítô programok
készülnek majd. Az UC2 szerzôje már írta is, hogy a jövô év
elején megjelenô, hordozható UC3-hoz fel fogja használni a
HA néhány ötletét.
@VPkZip 2.04g@N
A bevezetô szöveg után még annyit róla, hogy
hiányosságainak egyike: külön program végzi a kicsomagolást
és a tömörítést, s egy harmadik készíti az önkibontó file-t.
Elônye még a rendkívül kicsi (2750 byte-os) Pkunzip Junior
önkibontó (PKUNZJR.COM).
@VRAR 1.53@N
A program elsô indításra feltûnô tulajdonsága a
kinézete. Paraméter nélkül indítva megjeleníti az aktuális
könyvtárat, a jól megszokott Commander stílusban. Innen
billentyûzetrôl vagy egérrel kiválaszthatjuk a kívánt
file-okat, amelyeket akár az @KAdd@N feliratra kattintva, akár
az [F2] gombot megnyomva már tömöríthetünk is. [F5]-re (vagy
a @KVolume@N feliratra kattintva) megjelenik egy ablak, ahol
1000 vagy 1024 byte-os (1 Kbyte-os) egységekben megadhatjuk
a szelet- (volume-)méretet. Ugyanitt megtaláljuk a
szabványos DOS floppyméreteket is, és teljes kitöltést
(@KAutodetect@N) is kérhetünk.
Ha ez még nem lenne elég, a programban még van egy ZIP,
ARJ, RAR megjelenítô (viewer) is. Ezt úgy érhetjük el, hogy
kiadjuk (például) a @KRAR VALAMI.ZIP@N parancsot. A szokásos
mûveleteken -- kibontás, tesztelés stb. -- kívül néhány
különlegesség még ebben is van: van benne egy ASCII/hexa
nézôke, ami meglepôen sokat tud: van benne sortördelés,
keresés, képes Unix és Macintosh szövegeket is megjeleníteni
a DOS-osokon kívül, mert [F6]-tal kiválaszthatjuk a sorvég
jelet. A nézôkét a fô RAR képernyôrôl [F3]-mal hívhatjuk
meg. A viewer nemcsak megjeleníteni tud, segítségével
módosíthatunk is egy-egy file-t, vagy az archívum
megjegyzését. Ismétlem: ez nemcsak RAR file-okkal, hanem ZIP
és ARJ file-okkal is mûködik. Mindeme szolgáltatások
beleférnek egy tömörítve 80 Kbyte-os .EXE-be.
(Összehasonlításképpen: a Nazarenko Arcview 6.9-es verziója
tömörítve 36 Kbyte.) Csak egy dolog hiányzik -- ezt kívülrôl
kell megoldanunk, a mellékelt batch file-ok segítségével --,
a ZIP és ARJ archívumok átkonvertálása RAR formátumba.
A program nemcsak kezelésben, tömörítésben is igen jó.
Sajnos sebessége ennek megfelelôen szerényebb. A
szolgáltatásokban két igen fontos dolgot tud: egyik a
szeletelés. (Ez nagyon hasonlít az ARJ-éhez.) E program
mutatta be elôször az önkibontó szeleteket. (Az igazsághoz
az is hozzátartozik, hogy a legelsô Jakub Jelínek ARJVIEW
programcsomagjából az EXARJ volt. Ez képes ARJ szeletbôl
önkibontót varázsolni, de sajnos a kibontó rutinja nem volt
igazán tökéletes, így nem nagyon terjedt el.)
Az önkibontó archívumok létrehozása a fôképernyôn elég
nehézkes, mivel csak szeletelt önkibontót kérhetünk, de ha
elég nagy szeletméretet írunk be, akkor persze csak egyetlen
.EXE file jön létre. Ráadásul a név bekérésekor VALAMI.RAR-t
kínál fel VALAMI.EXE helyett, szerencsére ez módosítható.
Parancssorból semmi gond nincs, az @K/sfx@N kapcsoló elintézi az
egészet. Érdemes önkibontó RAR-t használni, mert az
önkibontó fejléc a legkisebb -- hihetetlenül rövid -- a
tesztelt programok között, és ennek ellenére minden lényeges
szolgáltatással rendelkezik. (Lásd még az önkibontókról
szóló táblázatot.)
A másik fontos tulajdonság az úgynevezett solid
archívumok kezelése. A hagyományos tömörítôprogramok a
file-okat külön-külön tömörítik, ezek egymás után kerülnek
az archívumba. A solid eljárás viszont kikeresi a file-ok
azonos részeit, ezeket a darabokat mindössze egyszer tárolja
el, a késôbbiekben csak hivatkozik rájuk. îgy jobb
tömörítést lehet elérni, ha file-ok hasonló szerkezetûek,
viszont e tömörségért sok idôvel fizetünk.
Van ennek az eljárásnak egy komoly veszélye: ha sérül az
archívum, akkor abból nemcsak a sérült file megy tönkre,
hanem az összes azt követô (pontosabban azzal összefüggô)
is. Emiatt e lehetôséget csak akkor használjuk ki, ha
valamilyen biztonságos médiát (nem floppyt) használunk, és a
file-oknak tényleg van közük egymáshoz. Az elsô
tömörítôteszt táblázatából kitûnik, hogy ott a file-oknak
például nem volt köze egymáshoz, így a solid archívum még
nagyobb is volt, mint az alapmódszerrel készült. Figyelembe
kell azonban venni, hogy ez igen ritka -- a valóságban
ritka, hogy egy archívumban ennyire ne legyen köze a
file-oknak egymáshoz. A második tesztben már látszik is,
hogy mennyivel tömörebb -- és lassabb -- a solid.
A hordozhatóság felé is megtette az elsô fontos lépést a
RAR. A csomagban benne van a kibontó forráskódja. Sebessége
megegyezik az eredeti kibontó sebességével, nem úgy, mint az
UNARJ-nál, amely deklaráltan nincs optimálva a sebességre. A
kibontás sebessége sajnos elég lassú, nem képes vetélkedni
sem a PkZip-pel, sem az AIN-nal.
@VUC2 r2, r3béta1@N
Az UC2-rôl már írtunk (CHIP 1994/6. 56. oldal): a többi
tömörítôvel szemben meglehetôsen lassú. Az általunk végzett
tesztben a HA-t nem számítva ez volt a leglassabb -- de a
legtömörebb is! Hibavédô algoritmusa nagyon értékessé teszi,
sokszor jön jól, ha védetten szállítható az archívum.
(Figyelem! Ez nem automatikus, be kell kapcsolni!)
A r3béta1-ben két új programmal találkozhattak a
bétatesztelôk: az UDIFF-fel és a Visual UC2-vel. Az UDIFF
szövegösszehasonlító program, kategóriájában jó közepes. A
Visual UC2 tömörítô shell program, ami befelé tud tömöríteni
az UC2-vel. Minden más mûveletre beállítható, hogy mit
csináljon: ha egy ZIP file-ra kattintunk, akkor melyik
archívumnézegetô jöjjön be, a képeket mivel akarjuk megnézni
stb. Az értéke kérdéses -- ha menüs archívumkezelôre van
szükségünk, ott a Shez és az Arcmaster. Mindenesetre tény,
hogy a RAR-hoz hasonlóan, igen kényelmesen tömörítgethetünk
befelé. Mérete 50 Kbyte, az UC2r2-é pedig 130, szóval nem a
legkisebb darabok.
Nagyon hiányzik hozzá a forráskód, az önkibontó és a
normális szeletelési lehetôség. A jövô év elejére várható
UC3-ban ezek várhatóan benne lesznek.
@VÉrtékelés@N
A tömörítô tesztbôl jól látható, hogy a HA kivételével
egyik program sem tud a többi fölé kerekedni tömörítésben.
Ellenben a sebességkülönbségek három-hatszorosak. Sôt a HA
több mint kilencvenszer (!) lassabb, mint a leggyorsabbnak
bizonyuló AIN -- a türelemért nem egészen 6%-kal tömörebb
archívum a jutalmunk. Nehéz végsô döntést hozni. ùgy tûnik,
hogy a ZIP-pel leginkább a RAR kelhet versenyre, bár
viszonylagos lassúsága ebben akadály lehet. Nagy kérdés,
hogy az AIN -- bár igen gyors -- mennyire tud elterjedni.
îgy Keleten és Nyugaton a helyzet (még) változatlan.
@KNégyesi Károly (CHX@CS.ELTE.HU)@N
@<9504\TOMOR1.GIF>■■@N A RAR Commander-szerû felülete
@<9504\TOMOR2.GIF>■■@N Az UC2 jelenleg bétatesztes shellje
@VA különbözô tömörítôk jellemzôi@N
A tömörségnél, a tömörítési sebességnél és a kibontási
(tesztelési) sebességnél a maximális tömörítésnél mért
helyezéseket adtuk meg.
■
Program neve AIN ARJ HA PkZip RAR UC2
Tömörség 3-4. 5. 1. 3-4. 3. 2.
Tömörítési sebesség 1. 3-4. 6. 2. 3-4. 5.
Kibontási sebesség 1. 3-4. 6. 2. 3-4. 5.
■
Szolgáltatások
■
Backup lehetôség - + - - - -
Biztonságos szeletelés + + - - + -
Hibavédett archívumok - - - - - +
Jelszóval védett archívum ++ + - + + -/++
Komment az archívumban - + - + ++ +
Módosítás ellenôrzés (AV) + + - + + +
Önkibontó archívum - + - + + -
Forráskód - kibontó teljes teljes kibontó -
Kényelmes shell-program - - - - + -(béta verzióban)
■
A HA és az UC2 közötti tömörségi eltérés kevesebb mint
2% a HA javára, viszont a HA szinte kivárhatatlanul lassú,
és csak szövegfile-ok tömörítésénél van elônyben.
A RAR különleges kommentezésre képes: ANSI (tehát
színes) kommentek építhetôk be az archívumokba, melyeket
ANSI.SYS nélkül is megtekintehetünk a RAR segítségével.
Az AIN jelszókezelése két dolog miatt igen jó és
érdekes: képes megváltoztatni az archívum jelszavát, és az
archívumot még listázni sem lehet a jelszó nélkül. Viszont a
jelszó csak az egész archívumra vonatkozhat, külön file-okra
nem tehetô jelszó. A program nagyon új, így az általa
használt jelszó-algoritmust komoly teszteknek még nem
vetették alá, de megbízhatónak tûnik.
Az UC2 jelszókezelése külön file-ba került (UCRYPT). Ez
jelenlegi tudásunk szerint nem törhetô algoritmusokat
használ, többet is egymásba ágyazva.
Az AV mindegyik programnál csak a regisztrált
felhasználóknak jár. Az UC2-ben ráadásul ez egy külön
program, amit csak a regisztrálás után kaphatunk meg, így
kisebb a feltörés esélye. Az UC2 AV-je (amit seal-nak nevez)
szintén külön programmal ellenôrizhetô. A ZIP-hez és a
RAR-hoz már léteznek úgynevezett AV crack-ek, így ezeknél @Kne@N
bízzunk meg az AV-ben!
@VAz önkibontó archívumok jellemzôi@N
■
Program neve ARJ ARJ jr. PkZip PkZip jr. RAR
Önkibontó fejléc mérete (byte) 16012 5971 11449 3002 1278
Ad-e helpet? + - + - +
Listázható? + - + - +
Megadható célpath? + + + ? +
Tesztelhetô? + - + - +
■
A PkZip Junior célpath-a rosszul mûködik. A @KZIPJR.EXE
valami@N parancsra az összes file neve elé odaírja a @Kvalami@N-t.
Ha az a @Kvalami@N tartalmazott elérési utat, akkor oda bontja,
ha nem, akkor csak rossz néven bontja ki. Ugyanígy nem képes
csak néhány, megadott file-t kinyitni, például a @KZIPJR.EXE
t*.*@N parancs hibával áll le.
Az UC2 önkibontó moduljából egyenlôre csak béta verzió
van (UC2 r3 béta2).
@VSaját tesztjeink egy elég vegyes file-koktéllal@N
E méréssorozatban a HA -- a bináris file-okkal való
""összeférhetetlensége" miatt -- nem szerepel.
Az eredeti file-ok (14 file, összesen 3869546 byte):
■
386INTEL TXT 877997
AIN EXE 36458
ALCHEMY EXE 893103
ARJ EXE 122094
AUTOMOBI DBF 1129050
COMMAND COM 48113
COMMAND1 BMP 223702
FORMATQM COM 12399
HUNDUMMY ZIP 261027
INS COM 99
PKZIP EXE 42552
RAR EXE 85909
TIMER EXE 3280
UC EXE 133763
■
COPY *.* NUL: 2.48s
Program és kapcsolók Becsomagolási idô Méret Tömörítési % Kibontási idô
AIN /m1 /u1 62,21s 1520068 39,28% 2,09s
AIN /m1 /u2 60,23s 1518248 39,24% 2,15s
AIN /m1 /u3 59,68s 1518173 39,23% 2,20s
AIN /m2 /u1 51,48s 1524265 39,39% 1,98s
AIN /m2 /u2 51,15s 1523080 39,36% 2,15s
AIN /m2 /u3 50,55s 1523021 39,36% 2,09s
AIN /m3 /u1 28,49s 1671002 43,18% 2,09s
AIN /m3 /u2 15,90s 1669158 43,14% 2,31s
AIN /m3 /u3 15,90s 1668452 43,12% 2,20s
AIN /m4 15,57s 3869940 100,01% 4,46s
ARJ /m0 21,45s 3870322 100,02% 13,48s
ARJ /m1/jm1 105,33s 1528555 39,50% 17,11s
ARJ /jm1 105,05s 1528556 39,50% 17,11s
ARJ /m1 94,27s 1529568 39,53% 17,11s
ARJ /m2 70,46s 1537755 39,74% 17,27s
ARJ /m3 51,92s 1577213 40,76% 17,60s
ARJ /m4 36,36s 1722599 44,52% 16,78s
RAR /m0 14,14s 3870148 100,02% 6,71s
RAR /m1 55,66s 1558277 40,27% 18,32s
RAR /m2 60,39s 1531816 39,59% 17,99s
RAR /m3 73,98s 1504835 38,89% 17,71s
RAR /m4 106,65s 1497000 38,69% 17,55s
RAR /m5 156,26s 1495234 38,64% 17,60s
RAR /m1 /s 59,40s 1559805 40,31% 18,26s
RAR /m2 /s 65,01s 1533295 39,62% 17,88s
UC2 /TST 298,21s 1487612 38,44% 20,41s
UC2 /TT 132,61s 1493280 38,59% 18,87s
UC2 /TN 113,30s 1503588 38,86% 18,92s
UC2 /TF 98,67s 1529212 39,52% 19,14s
ZIP /e0 19,14s 3870900 100,03% 5,17s
ZIP /ex 111,82s 1512046 39,08% 8,91s
ZIP /en 62,32s 1522429 39,34% 9,02s
ZIP /ef 46,64s 1557069 40,24% 9,24s
ZIP /es 30,25s 1679626 43,41% 9,74s
@VTesztsorozat szövegfile-okkal@N
A sok hasonló szövegfile tömörítése elsôsorban a solid
tömörítési módszer, valamint a HA tömörítési hatékonyságát
reprezentálja.
A felhasznált file-ok:
■
név kiterjesztés méret (byte)
ASIMOV 01 31818
ASIMOV 02 29644
C FAQ 41529
COMPRESS 1 126249
COMPRESS 2 92565
COMPUTER ART 5332
■
FTP_FAQ 53148
■
HW_FAQ 01 76729
HW_FAQ 02 66588
HW_FAQ 03 100105
HW_FAQ 04 68217
HW_FAQ 05 83969
MSDOS FAQ 142816
NETFAX FAQ 14582
TOLKIEN 01 32683
TOLKIEN 02 45831
TOLKIEN 03 42291
UNIX_FAQ 00 10010
UNIX_FAQ 01 19241
UNIX_FAQ 02 39705
UNIX_FAQ 03 34203
UNIX_FAQ 04 29229
UNIX_FAQ 05 12346
UNIX_FAQ 06 40103
UNIX_FAQ 07 15697
■
Ezeken kívül még 121 kisebb szövegfile, 2681 byte hosszban,
így a teljes összméret 1257311 byte.
■
Program és kapcsolók Tömörítési idô Méret (%) Tesztelési idô
AIN /m1/u1 24,92s 431379 (34,3%) 1,83 s
AIN /m1/u2 24,31s 436010 (34,7%) 1,83 s
AIN /m1/u3 22,66s 446856 (35,5%) 1,83 s
AIN /m3/u1 15,29s 506652 (40,3%) 1,82 s
AIN /m3/u2 13,59s 508272 (40,4%) 1,82 s
AIN /m3/u3 14,14s 512668 (40,8%) 1,81 s
ARJ /m1 50,27s 456979 (36,4%) 8,86 s
ARJ /m4 24,97s 535082 (42,6%) 10,23 s
HA A12 577,50s 389064 (30,9%) 201,14 s
HA A21 559,74s 389064 (30,9%) 201,14 s
HA A2 629,81s 389074 (30,9%) 208,32 s
HA A1 358,82s 442556 (35,2%) 42,79 s
RAR /m1 25,58s 482770 (38,4%) 9,19 s
RAR /m1/s 25,58s 467063 (37,2%) 8,80 s
RAR /m5 48,73s 449889 (35,8%) 9,24 s
RAR /m5/s 67,38s 427112 (34,0%) 8,42 s
UC2 ATST 99,28s 410680 (32,7%) 11,66 s
UC2 AF 38,94s 436954 (34,8%) 11,99 s
ZIP /ex 32,29s 459070 (36,5%) 5,01 s
ZIP /es 12,16s 529266 (42,1%) 5,23 s
■